Traffic Performance Optimization Overview

 

 

This chapter provides an overview of the Traffic Performance Optimization (TPO) in-line service.

TPO is a licensed in-line service supported on the Cisco ASR 5000 chassis running any of the following products:

 

•

GGSN

•

HA

•

PDSN

•

P-GW

The following topics are covered in this chapter:

 

•

Overview

•	Feature Specifications

•	How TPO Works

 

Overview

Though TCP is a widely accepted protocol in use today, it is optimized only for wired networks. Due to inherent reliability of wired networks, TCP implicitly assumes that any packet loss is due to network congestion and consequently invokes congestion control measures. However, wireless links are known to experience sporadic and usually temporary losses due to several reasons, including the following, which also trigger TCP congestion control measures resulting in poor TCP performance.

Reasons for delay variability over wireless links include:

 

•	Channel fading effect, subscriber mobility, and other transient conditions

•	Link-layer retransmissions

•	Handoffs between neighboring cells

•	Intermediate nodes, such as SGSN and e-NodeB, implementing scheduling polices tuned to deliver better QoS for select services — resulting in variable delay in packet delivery for other services

The TPO in-line service uses a combination of TCP and HTTP optimization techniques to improve TCP performance over wireless links.

 

TPO Deployment

TPO uses the Enhanced Charging Service (ECS) framework for TCP Proxy functionality, and as depicted in the following figure, it is part of the ECS module in the Gateway.

 

TPO Deployment

TPO uses the TCP Proxy to split end-to-end TCP connections between the client and server into two separate TCP connections, and apply the TCP and HTTP optimization techniques in the TCP stack towards the client. The split TCP connections isolate impacts of packet errors and delay variability for the wireless link from the wired connection, so that TCP congestion control, timeout, and retransmission mechanisms in the wired link do not suffer from the fluctuating quality of the radio channel.

Important: In this release TPO optimizes only downlink radio usage.

 

TPO Optimization Model

 

Feature Specifications

This section describes features of the TPO in-line service.

 

Licensing

TPO is a licensed in-line service feature requiring the following license to be installed on the chassis:

Cisco PID [ ASRK-00-CS0ITRPO ] Traffic Packet Optimization,1K sessions, or Starent part number [ 600-00-7523 ] Optimization.

For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

 

Supported Standards

TPO is based on the following RFCs and standards:

 

•	RFC 793 Transmission Control Protocol; 1981-09

•	RFC 2616 Hypertext Transfer Protocol — HTTP/1.1; 1999-06

•	RFC 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks; 2003-02

 

TCP Optimization

To improve TCP performance over wireless links TPO uses TCP optimization techniques that enable:

 

•	Improved downlink throughput during periods of congestion

•	Closer to theoretical bandwidth utilization by reducing TCP overheads

•	Adoption to wireless network events and conditions optimizing data transmission rate for available bandwidth and RTT

•	Minimized TCP retransmissions

 

TCP Optimization Techniques

This section describes the TCP optimization techniques supported by TPO.

Selection of the optimization techniques to gain TCP performance depends on the network characteristics and the prevalent wireless conditions. To trigger appropriate congestion control techniques for a given situation based on the wireless events, TPO utilizes available information such as subscriber QoS, system load, and so on.

 

Optimizations in TCP Three-way Handshake

During TCP Three-way Handshake, the TCP client and server negotiate to establish a connection. TCP requires three round-trip time (RTT) measurements between the client and server before data transfer is initiated. Determining the RTT adds extra time for each wireless connection.

TPO supports the following optimizations during TCP Three-way Handshake:

 

•	TCP options such as SACK and timestamp are negotiated.

•	RTT is calculated based on Timestamp.

 

Optimizations in TCP Slow Start Phase

During TCP Slow Start phase, to discover available bandwidth for a connection, TCP calculates the lowest possible bandwidth and increases exponentially until a packet loss is detected. In wireless environments, this phase implies periods during which the link is under-utilized and perceived by the subscribers as slow.

TPO supports the following fast start techniques:

 

•	TPO uses subscriber QoS settings to set the initial congestion window.

The subscriber QoS information is received from the AAA/OCS.

•	TPO uses information from other TCP connections to set the initial congestion window, which is based on the RTT and used bandwidth for the other connection(s).

•	TPO allows to configure the initial congestion window to any of the following values:

•	Units of 1 through 255 MSS segments.

•	A dynamically computed value at runtime, which is calculated as a percentage of bandwidth-delay product (BDP). The bandwidth is a CLI-configured value, and the delay is calculated using the SYN-ACK exchange.

•	A value recommended by RFC 5681, which varies from 2 through 4 based on MSS. This the default setting.

 

Optimizations in TCP Congestion Avoidance Phase

In the TCP Congestion Avoidance phase, TCP after detecting available bandwidth for a new connection linearly adjusts the congestion window to discover incremental bandwidth.

TPO allows to configure any of the following congestion control algorithms:

 

•

TCP Westwood Plus: The TCP Westwood Plus algorithm can significantly increase throughput over wireless links. It relies on end-to-end bandwidth estimation to discriminate the cause of packet loss — congestion or wireless channel effect. The bandwidth estimate is determined by measuring and averaging the rate of returning acknowledgements. This estimate is then used to compute the congestion window and slow start threshold after a congestion episode.

•	Vegas: The Vegas algorithm instead of relying on detection of packet loss, uses a bandwidth estimation scheme to proactively gauge network congestion. The Sender watches for signs of congestion is setting in, such as RTT growing and sending rate flattening.

•	Basic: This is a custom TCP congestion algorithm based on the TCP Reno algorithm. This is the default setting.

 

Fast Retransmits

To guarantee reliability of transfers, TCP requires the Receiver to respond to the Sender with an acknowledgment for each segment it receives. The Sender keeps a record of each segment it sends, and waits for an acknowledgment before sending the next segment. If the Sender does not receive an acknowledgment within the timeout period, under the assumption that the segment was lost in the network, the Sender fast-retransmits that segment (that is, retransmit without waiting for retransmission timeout (RTO)).

The Receiver will generate duplicate acknowledgements for every out-of-order (OOO) packet it receives. If the Sender receives three duplicate acknowledgements with the same acknowledgement number (that is, a total of four acknowledgements with the same acknowledgement number), the Sender decides that the segment with the next higher sequence number was dropped, and will not arrive out of order. The Sender will then fast-retransmit that segment.

TPO supports the following optimization with fast retransmits:

 

•	TPO allows to configure the number of duplicate acknowledgements that will trigger fast retransmits. This can be:

•	Static value: When high amount of re-ordering is present in the network the static threshold of three duplicate acknowledgements does not work well. Under such conditions a higher static value is required as the threshold. This is a CLI-configurable parameter and can be a value 1 through 10.

However, note that a higher static value will sometimes lead to not reaching the threshold because of less number of in-flight packets (which will roughly determine the number of duplicate ACKs received by the sender).

•	Dynamic value: The duplicate acknowledgement threshold is dynamically computed at runtime based on the number of in-flight packets (one-third of the in-flight packets, subject to a minimum of two). This will enable to adapt in networks where high amount of packet re-ordering is observed.

 

TCP Handoff Optimization

TPO supports intra-tech and inter-tech handoff events.

When an intra-tech handoff is detected, TPO takes the following actions:

 

1.	Restarts RTT/RTO calculation based on first packet sent after the handoff.

2.	Ignores duplicate acknowledgements as congestion event. Considers duplicate acknowledgements as packet drops due to handoff for next one RTT.

3.	If RTO is triggered after the handoff event, for the next RTT, ignores congestion window adjustment.

4.	If RTO happens and then handoff event is received, undoes congestion window due to RTO.

5.	Restarts BWE for Vegas and Westwood congestion control algorithms.

6.	Handles one handoff event per X RTT only.

When an inter-tech handoff is detected, TPO takes the following actions:

 

•	Handoff Pre-event: As soon as bearer creation request is received at the gateway:

1.	Stops forwarding packets when handoff pre-event is received.

2.	Stops RTO and retransmission.

•	Handoff Post-event: When bearer creation is complete at PGW/GGSN, restarts congestion control algorithm. This will take care of resending old unacknowledged packets.

Enabling/disabling TCP Handoff Optimization is a CLI-configurable parameter.

 

Retransmission Timeout Optimizations

TPO allows to configure the scaling factor for Round Trip Time Variation (RTTVAR). The configured scaling factor is used as a power of 2, so values of 0 through 4 correspond to 1, 2, 4, 8, and 16. In TCP RTO is calculated using the following formula:

RTO = SRTT + K*RTTVAR

where:

 

•	SRTT = mean Round Trip Time (RTT)

•	RTTVAR = Round Trip Time Variation

As wireless networks exhibit high RTT variation, the value of K is configurable. The value of K decides the extent to which Retransmission Timeout (RTO) timer depends on RTT variance. If RTT variance is higher, then K should be higher. The default RTTVAR scaling value, as recommended by RFC 2988, is 2.

TPO also allows to configure the RTO retransmission back-off factor. Once RTO fires for a packet, TCP will retransmit that packet and set the RTO to be a factor X, which is CLI-configurable, of the previous RTO. The default RTO backoff value, as recommended by RFC 5681 is 2.0.

 

Duplicate Selective Acknowledgement Support

Duplicate Selective Acknowledgement (D-SACK), an extension to SACK, allows the TCP receiver to report duplicate segment that it receives so the sender can infer when it has unnecessarily retransmitted a packet. Once D-SACK has been detected by the TCP sender, it can take necessary actions to reduce the spurious retransmissions.

The primary cause of these retransmissions could be network re-ordering resulting in three duplicate acknowledgements (Fast Retransmits) based retransmission, or due to a sudden change in network latency resulting in RTO being triggered.

D-SACK uses the first block of SACK option to specify the sequence numbers for the duplicate segment that triggers the acknowledgement. The TCP receiver sends a D-SACK when a segment is received with sequence numbers lower than the cumulative acknowledgment. D-SACK block also reports duplicate segment from (possibly larger) block of data in the receiver buffer above the cumulative acknowledgement, and here the second SACK block (the first non D-SACK block) specifies this (possibly larger) block.

In this release, TPO only addresses spurious retransmissions caused by three duplicate acknowledgements (Fast Retransmits). This is done by changing the Fast Retransmit threshold to an appropriate value higher than the default value of 3.

On detecting a D-SACK block, the TCP sender starts to monitor the reordering in the network and changes the fast retransmission threshold accordingly to avoid spurious fast retransmissions due to reordering. Every duplicate acknowledgement received after detecting a D-SACK block is considered as acknowledgement to an out-of-order segment. So when a duplicate acknowledgement is received the maximum reordering in the network is calculated using the SACK blocks received since the SACK block contains information about the out-of-order segments that are successfully received by the TCP receiver. A version of this calculated level of reordering is used to tune the Fast Retransmit threshold. After the Fast Retransmit threshold is changed, the successful acknowledgements (for in-order segments) is also continuously monitored and is used to further tune this threshold to an appropriate value. This results in achieving a threshold that correctly reflects network reordering.

Another action that is taken on detecting D-SACK is to adjust the congestion window. On retransmitting a packet (fast-retransmit) TCP sender reduces/adjusts the congestion window (as per the Congestion Control algorithm). When D-SACK is detected, it would mean that the retransmission was spurious and the reduction/adjustment in congestion window that was done was unnecessary and it could be set back to the original value.

 

HTTP Optimizations

To optimize incoming HTTP payload over TCP connections TPO uses HTTP optimization techniques that enable:

 

•	Reducing payload by compressing text-based Web pages (packet headers are not compressed), albeit such pages do not account for much traffic and Web servers themselves could do the compression

•	Minimizing number of round trips from clients, enabling faster response time

•	Reducing payload by filtering advertisements

 

HTTP Optimization Techniques

This section describes HTTP optimization techniques supported by TPO.

 

HTTP Compression

The HTTP Compression feature enables to compress HTTP content transferred to the mobile client. HTTP Compression, by reducing the amount of traffic to be transported, enables better use of available bandwidth and improves transmission speeds.

Important: In this release TPO supports only the standards-based gzip compression algorithm.

Note that TPO will not attempt compression in the following cases:

 

•	If the mobile client cannot accept compressed encodings

•	If the HTTP version used is earlier than 1.1

•	If the response from the Web server is already compressed

Enabling/disabling the HTTP Compression feature is a CLI-configurable parameter. By default HTTP Compression is disabled.

Compression level is a CLI-configurable parameter. Compression levels 1 through 9 are supported. The higher the compression level, the better the compression efficiency but with increased CPU and memory utilization. By default the compression level is set to 6.

TPO supports Prevention of Compression at the Web server. This enables TPO to receive uncompressed data from the Web server, on which it can apply other HTTP optimization techniques, and then compress the optimized data and send it to the mobile client. TPO achieves this by manipulating the HTTP requests. Enabling/disabling this feature is a CLI-configurable parameter. By default, the Prevention of Server Compression feature is disabled.

The following figure and steps explain how the HTTP Compression feature works:

 

HTTP Compression

1.	Mobile client’s browser in its HTTP request for HTML content incudes an Accept-Encoding field with comma separated list of supported compression schema names.

2.	TPO forwards the HTTP request to the Web server.

3.	If the Web server does not support the compression schema(s) in the Accept-Encoding field or cannot undertake compression, in the HTTP response it sends the uncompressed data.

If the Web server supports the compression schema(s) in the Accept-Encoding field, in the HTTP response the Web server may send the compressed data, and include the Content-Encoding field with name(s) of the compression schema(s) used. TPO forwards the HTTP response to the mobile client.

4.	If the Web server in its response sends uncompressed data, TPO compresses the data and then uses internal thresholds for amounts of internal resources available compared to the amount of packet size reduction achieved.

If the comparison is favorable, TPO forwards the compressed response to the mobile client, and any subsequent response packets are also compressed. TPO updates the Content-Encoding field with name(s) of the compression schema(s) used. The mobile client’s browser parses the requested data and displays it.

If the comparison is not favorable, TPO forwards the original response to the mobile client and then forwards any subsequent response packets.

 

URL Rewrite

The URL Rewrite feature enables to preemptively resolve host names in embedded URLs present within HTML content and rewrite them with resolved IP addresses. This rewriting helps to eliminate DNS round trips in high latency mobile networks resulting in faster responses.

Enabling/disabling the URL Rewrite feature is a CLI-configurable parameter. By default the URL Rewrite feature is disabled.

Important: The URL Rewrite feature needs a valid DNS client to be configured in the ISP (destination) context.

When the URL Rewrite feature is enabled, TPO rewrites URLs of the following format

http://<host_name[:port]>/<url_path>/<file_name.extension>

into

http://<resolved_ip_address[:port]>/<url_rewrite_prefix>/<host_name[:port]>/<url_path>/<file_name.extension>

For example, if the URL Rewrite prefix is urlrewrite, TPO rewrites the URL

http://www.google.com/test.img

into

http://209.85.153.103/urlrewrite/www.google.com/test.img

When the mobile client requests for the URL

http://<resolved_ip_address[:port]>/<url_rewrite_prefix>/<host_name[:port]>/<url_path>/<file_name.extension>

TPO rewrites the URL back to

http://<host_name[:port]>/<url_path>/<file_name.extension>

The URL Rewrite prefix is a CLI-configurable parameter. By default, the prefix is set to “urlrewrite”.

URL Rewrite works only on HTML content, hence it is called only in the following cases:

 

•	Content in response to HTTP GET request where MIME type of the content is HTML/CSS/JavaScript

•	Content is not encoded

TPO rewrites only those URLs that are present in the following HTML tags:

 

•

image

•

imagepath

•

img

•

input

•

link

•

script

Important: URLs that are part of JavaScript and VBScript are not rewritten. If an HTML tag spans across packets, TPO will queue only two packets and will rewrite the URL if found.

The following figure and steps explain how the HTTP URL Rewrite feature works:

 

HTTP URL Rewrite

1.	The mobile client sends HTTP request for HTML content.

2.	TPO forwards the HTTP request to the Web server.

3.	The Web server sends an HTTP response with the requested HTML content.

4.	TPO resolves host names in embedded URLs present within the HTML content and rewrites them with corresponding IP addresses.

5.	TPO forwards the HTTP response to the mobile client.

6.	The mobile client’s browser parses the HTML and sends HTTP requests for images and other content to the modified URLs.

7.	TPO rewrites the URLs and forwards the HTTP requests to the Web server.

8.	The Web server returns HTTP response with the requested content.

9.	TPO forwards the HTTP response to the mobile client.

In case both HTTP Compression and URL Rewrite features are enabled, URL Rewrite processing will happen before HTTP Compression.

 

Advertisement Filter

The Advertisement Filter feature enables to block advertisement content in Web pages delivered to mobile clients. This filtering reduces over-the-air bandwidth usage as advertisements are not always downloaded, and faster response times as advertisement-related server connections are eliminated.

Important: In this release, TPO considers only images and Flash objects as advertisements.

TPO is configured with URLs of the advertisement sites to be blocked, typically sites such as www.doubleclick.net/*, ad.yahoo.com, and so on. When the mobile client’s browser receives HTML content, it parses the HTML and sends out requests for images and other content. If there is a request for an image or Flash object whose URL matches any of the URLs to be blocked, TPO blocks the advertisement as per the configuration.

The Advertisement Filter feature supports the following advertisement blocking methods:

 

•	Advertisement Blocking with NO Text: In the mobile client’s browser each blocked advertisement is replaced with the “cannot display image” icon (usually an X mark). Subscribers cannot view the advertisements even if they want to.

•	Advertisement Blocking with Text: In the mobile client’s browser each blocked advertisement is replaced with a placeholder frame. Each placeholder frame contains standard operator-configured text and the advertisement’s URL. Subscribers cannot view the blocked advertisements even if they want to.

•

Advertisement Blocking with On-click Function: In the mobile client’s browser each blocked advertisement is replaced with a placeholder frame. Each placeholder frame contains standard operator-configured text and the advertisement’s URL. To view a blocked advertisement the subscriber must click the placeholder frame.

To enable retrieving the blocked advertisement, in the HTTP request a bypass string is added to the advertisement’s URL, which TPO interprets and forwards to the Web Server allowing the advertisement to be retrieved. The bypass string is a CLI-configurable parameter.

The background color of the placeholder frames and the text displayed in them are CLI-configurable parameters. Operators can use the text to indicate that the advertisement is blocked. Note that different text strings can be configured for “Advertisement Blocking with Text” and “Advertisement Blocking with On-click Function” configurations.

Important: The text string and URL displayed in the placeholder frames may be truncated to fit dimensions of the frames.

Important: The “Advertisement Blocking with Text” and “Advertisement Blocking with On-click Function” Advertisement Filter functionality is achieved using JavaScript code sent from TPO and executed whenever a Web page is loaded in the mobile client’s browser. If the mobile client’s browser does not support JavaScript or the subscriber has disabled JavaScript, instead of the placeholder frames the subscribers will see the “cannot display image” icons.

 

Basic Advertisement Blocking

The following figure and steps explain how the basic advertisement blocking feature works.

 

Basic Advertisement Blocking

•	The mobile client sends HTTP request for HTML content.

•	TPO forwards the HTTP request to the Web server.

•	The Web server sends an HTTP response with the requested HTML content.

•	TPO forwards the HTTP response to the mobile client.

•	The mobile client’s browser parses the HTML and sends HTTP requests for images, Flash objects, and other content.

•	If there is an HTTP request for an image or Flash object, TPO matches the requested URL with the list of advertisement URLs to be blocked.

If there is a match, TPO responds with Content-Length 0 for the request thereby blocking the advertisement. In the mobile client’s browser, the image or Flash object is replaced with the “cannot display image” icon.

 

Advertisement Blocking with On-click Function

The following figure and steps explain how the Advertisement Blocking with On-click feature works.

 

Advertisement Blocking with On-click Function

 

1.	The mobile client’s browser sends an HTTP request for HTML content.

2.	TPO forwards the HTTP request to the Web server.

3.	The Web server sends an HTTP response with the requested HTML content.

4.	TPO forwards the HTTP response to the mobile client’s browser along with a JavaScript code containing the list of advertisement site URLs to be blocked.

5.	The mobile client’s browser parses the HTML and sends HTTP requests for images, Flash objects, and other content.

6.	If there is an HTTP request for an image or a Flash object, TPO matches the requested URL with the URLs to be blocked. If there is a match, TPO responds with local content based on the requested file’s extension.

7.	JavaScript in the mobile client’s browser parses the HTML to check for blocked images and Flash objects, and replaces them with placeholder frames. If “Advertisement Blocking with On-click Function” is enabled, on-click functionality is added to the frames.

When the subscriber clicks the placeholder frame for a blocked image or Flash object, the mobile client’s browser sends an HTTP request with a bypass string appended to the requested URL.

8.	TPO forwards the HTTP request to the Web server.

9.	The Web server sends an HTTP response with the requested data.

10.	TPO forwards the HTTP response to the mobile client’s browser. The mobile client’s browser displays the requested advertisement content.

 

Session Recovery

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

Session recovery is performed by mirroring key software processes (for example, Session Manager and AAA Manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (for example, a Session Manager task aborts). The system spawns new instances of “standby mode” session and AAA Managers for each active Control Processor (CP) being used.

Additionally, other key system-level software tasks, such as VPN Manager, are performed on a physically separate packet processing card to ensure that a double software fault (for example, Session Manager and VPN Manager fails at same time on same card) cannot occur. The packet processing card used to host the VPN Manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

For more information on Session Recovery, refer to the Session Recovery chapter in the System Administration Guide.

 

Inter-Chassis Session Recovery

Important: TPO-ICSR support is available only in 12.2 and later releases.

The ASR 5000 chassis provides industry leading carrier class redundancy. The system protects against all single points of failure (hardware and software) and attempts to recover to an operational state when multiple simultaneous failures occur.

The Inter-chassis Session Recovery (ICSR) feature allows for continuous call processing without interrupting subscriber services. This is accomplished through the use of redundant chassis. The chassis are configured as primary and backup with one being active and one in recovery mode. A checkpoint duration timer is used to control when subscriber data is sent from the active chassis to the inactive chassis. If the active chassis handling the call traffic goes out of service, the inactive chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session. The chassis determines which is active through a propriety TCP-based connection called a redundancy link. This link is used to exchange hello messages between the primary and backup chassis and must be maintained for proper system operation.

When configured, the TPO policy ID mapping (TPO policy name and TPO policy ID) is exchanged from the active SessMgr to the standby SessMgr. The microcheckpoint records from the active SessMgr to the standby SessMgr for every session only contains the TPO policy ID instead of the bigger sized TPO policy name. This TPO policy ID in the microcheckpoint is used to look up the TPO policy ID mapping at the standby SessMgr to get back the TPO policy name for the session.

For more information on ICSR, refer the Interchassis Session Recovery chapter in the System Administration Guide.

 

TPO Administration

This section describes TPO administration activities and covers the following topics:

 

•	DisablingEnabling TPO Optimizations

•	MUR Reporting for TPO

•	Switching TPO Policy

 

Disabling/Enabling TPO Optimizations

The TPO in-line service allows to disable/continue TPO optimizations when a peer-to-peer (P2P) flow is detected. This is a CLI-configurable feature.

Important: In this release, on disabling TPO optimizations only TCP-based optimizations are disabled. Disabling HTTP-based optimizations will be supported in a future release.

 

MUR Reporting for TPO

This section lists the EDR fields supported for TPO - MUR integration.

The Mobility Unified Reporting (MUR) is a Web-based application providing a unified reporting interface for a variety of data from Cisco Systems in-line service and storage applications. For more information on the MUR, see the Mobility Unified Reporting System Online Help.

The following are the EDR generation points:

 

•	End of TCP connection

•	End of HTTP transaction

The following EDR fields are supported for TPO - MUR integration:

 

•	TCP flow related fields:

•	TCP data transferred

•	TCP duration

•	TPO enable/disabled

•	HTTP transaction related fields:

•

HTTP URL

•	HTTP DNS local resolutions

•	HTTP DNS server resolutions

•	HTTP compression bytes in

•	HTTP compression bytes out

•	HTTP advertisement replaced (advertisement blocked)

•	HTTP advertisement delivered (advertisement accessed)

•	TPO enabled/disabled

 

Switching TPO Policy

TPO allows to switch a TPO policy in use with a different TPO policy.

Important: The switch takes effect only on current calls. For new calls, the RADIUS-returned/APN/subscriber template configured policy is used.

To be able to change the TPO policy in mid session, TPO must have been enabled for the subscriber in the APN/Subscriber template configuration during call setup.

The CLI indicates the number of sessions for which the policy got switched.

 

How TPO Works

This section describes how TPO works.

 

Terms and Definitions

The following is a list of terms specific to TPO functionality:

 

•	TPO Policy: A TPO policy specifies the match-rule definitions to select a TPO profile. The match-rule definitions enable to use different sets of optimizations for different TCP/HTTP flows of a subscriber.

The TPO policy to be used for a subscriber can be from one of the following:

•

AAA/OCS: The TPO policy can come from the AAA server or the OCS. During initial authentication the AAA server returns the TPO policy for the subscriber, which is applied to the corresponding session. For this purpose the system uses the RADIUS AVP SN-TPO-Policy. If the policy comes from the AAA/OCS, it will override the policy configured in the subscriber’s APN/subscriber template and/or the ECS rulebase.

Important: The TPO policy received from the AAA and OCS have the same priority. Whichever comes first, either from AAA or the OCS, is applied.

•	APN/Subscriber Template: If no TPO policy is received from the AAA/OCS, the TPO policy configured in the subscriber’s APN/subscriber template is applied to the flows over the sessions using that APN/subscriber profile.

•

ECS Rulebase: The default TPO policy configured in the ECS rulebase has the least priority. If no TPO policy to use is received from the AAA/OCS, and there is no TPO policy configured in the subscriber’s APN/subscriber template, only then will the default TPO policy configured in the ECS rulebase be used.

A maximum of 2048 TPO policies can be configured in the system.

•	TPO Profile: A TPO profile specifies the optimizations to be performed for a specific flow. A maximum of 2048 TPO profiles can be configured in the system. A TPO profile can be used in more than one TPO policy.

•	Ruledef: A ruledef specifies the criteria to identify a specific flow, such as HTTP flow to google.com. The criteria matches one or more protocol fields and/or protocol-state information supported by the protocol analyzers.

In 12.2 and later releases, both charging and TPO ruledefs can be used in match-rule and match-ad configurations. However, ruledef/group-of-ruledef statistics will be computed only for TPO ruledefs. Charging ruledefs/group-of-ruledefs are allowed only to provide backward compatibility and statistics are not computed in this case. It is recommended that TPO ruledefs be used within TPO policies so that rule statistics are available.

•	Rulebase: A rulebase specifies the protocol analyzers that run, and which packets they should analyze. Within a rulebase, ruledefs are specified to select the appropriate analyzers. Also within a rulebase, a collection of ruledefs are associated with charging actions.

•

Charging Action: A charging action specifies the action to be taken when a ruledef is matched. Many possible actions are possible, such as an action could indicate whether to count retransmitted packets for a subscriber, or it could be to disconnect the subscriber upon certain protocol specific triggers.

•	Subscriber Profile/APN: The subscriber profile/APN specifies the TPO policy to be applied to the flows over the sessions using that subscriber profile/APN.

 

TPO Processing

TPO can be enabled in either of the following ways:

 

•	Policy-based TPO processing: On all flows of a subscriber based on the TPO policy specified by the AAA/OCS, APN/subscriber template, or the ECS rulebase.

•	Charging Action-based TPO processing: On specific flows of a subscriber based on the flow matching a charging action with a TPO profile configured in it.

 

Policy-based TPO Processing

The following steps describe how policy-based TPO processing works:

 

1.	When a subscriber initiates a data session, the TPO policy from the AAA/OCS, or the TPO policy configured in the subscriber’s APN/subscriber profile, or the ECS rulebase is associated with that data session.

2.	When a flow is created over the session (as when the subscriber initiates a browsing session), first the ECS routing ruledefs are applied to determine the protocol analyzer (such as HTTP).

3.	The optimization ruledefs configured in the TPO policy are applied one after the other, in the specified order. When a match is found, the optimizations configured in the corresponding TPO profile are applied to the session.

During the course of a flow, first the match-rule logic is applied at SYN time — this mostly results in a default match-rule that selects the default TPO profile. This is because many of the match-rule conditions would not apply at SYN time. The match-rule is generally more useful with deep-packet inspection (DPI). During DPI, when the complete HTTP header information is received, the match-rule is invoked and a new TPO profile (if any) is obtained and applied. This new TPO profile (selected during DPI) will be used to perform HTTP optimization. However, the original TPO profile selected during SYN time will be used for TCP optimization.

If the first SYN does not match any TPO profile (in the absence of a default match rule), TPO is not applied to that flow. In 12.0 and later releases, with dynamic TCP Proxy this is no longer the case.

Important: The match-rule is also invoked after the HTTP request line is received. At this time, a TPO profile is used to only apply the advertisement block rule (if any). This is required to block any unwanted HTTP request packets for and advertisement site that could be potentially sent to the server. None of the other rules are applied even if present in the profile.

 

Charging Action Based TPO Processing

The following steps describe how charging action based TPO processing works:

 

1.	When a flow is created (as in when the subscriber initiates a browsing session), ECS routing ruledefs are applied to determine the protocol analyzer (such as HTTP).

2.	Based on the ECS rule matching the charging action to apply to the flow is selected.

3.	If a TPO profile is configured in that charging action, optimizations configured in that TPO profile are applied on the flow.

Important: In this release, when the TPO profile specified by a charging action is applied on a flow, only TCP optimizations and the decision to cease/continue TPO optimizations for P2P flows will be controlled by that TPO profile. HTTP optimizations will not be affected.

When the TPO profile specified by a charging action is applied on a flow, and subsequently a different charging action that does not have a TPO profile configured in it is applied on the same flow, TPO will not be disabled.

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883